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Data packet numbering in packet-switched data transmission 



BACKGROUND OF THE INVENTION 

[0001] The invention relates to packet-switched data transmission, 
antl more precisely, to optimization of data packet numbering, particularly in 
5 connection with acknowledged data transmission. 

[0002] One of the aims in the development of third-generation mo- 
bile communication systems, which are called e.g. the UMTS (Universal Mo- 
bile Communication System) and the IMT-2000 (Internationa! Mobile Tele- 
phone System), has been as good compatibility as possible with the second- 

10 generation mobile communication systems, such as the GSM system (Global 
System for Mobile Communications). For example, the core network of the 
UMTS system is designed to be built on the basis of the GSM core network, 
which allows as efficient utilization of the existing networks as possible. A fur- 
ther object is to enable third-generation mobile stations to perform handover 

15 between the UMTS and the GSM systems. This also applies to packet- 
switched data transmission, particularly between the UMTS and the packet 
radio network GPRS (General Packet Radio Service) designed for the GSM 
system. 

: [0003] In packet-switched data transmission we can employ reli- 

:20 able, i.e. acknowledged, transmission or unreliable, i.e. unacknowledged, 
transmission. In acknowledged data transmission the receiver sends an ac- 
knowledgement of received data packets PDU (Protocol Data Unit) to the 
transmitter, and thus the transmitter can retransmit lost or damaged packets. 
When inter-SGSN (Serving GPRS Support Node) handover is performed in 

25 the GPRS system, reliability of data transmission is ensured by means of an 8- 
bit N-PDU number (Network PDU) which is attached to data packets and used 
for checking which data packets were transmitted to the receiver. !n the UMTS 
system according to the current specifications, a 12-bit RLC sequence number 
of the RLC layer (Radio Link Control) of the packet data protocol is used for 

30 guaranteeing reliability of handover between serving support nodes in packet- 
switched data transmission. 

[0004] In handover from the GPRS to the UMTS, the UMTS system 
is responsible for reliability of handover. The reliability is checked by means of 
N-PDU numbers of the GPRS, which are used for generating identification 

35 numbers to be used in the handover process in the UMTS. When handover is 



performed from the UMTS to the GPRS, the GPRS system is responsible for 
the handover, in which case reliability is checked on the basis of the identifica- 
tion data of data packets included in the UMTS. For this purpose, an 8-bit data 
packet number has been designed for the UMTS system, which is added as 
5 an additional byte to a data packet of a convergence protocol layer PDCP 
(Packet Data Convergence Protocol) belonging to the UMTS data packet pro- 
tocol. This PDCP-PDU number thus forms a data packet number which logi- 
cally corresponds to the N-PDU number of the GPRS and on the basis of 
which it is checked during handover whether all data packets have been 

10 transmitted reliably. It is also possible to form the 8-bit PDCP-PDU number 
from 12-bit RLC sequence numbers by removing the four most significant bits. 
Corresponding PDCP-PDU, i.e. N-PNU, numbering can also be used in inter- 
nal handover between radio network subsystems in the UMTS (SRNS Reloca- 
tion). Data packets PDU are inserted into a buffer to wait until handover has 

15 been performed to a serving support node SGSN of another system or to a 
new serving radio network subsystem SRSN in the internal handover in the 
UMTS, and the transmitted data packets can be removed from the buffer as 
an acknowledgement of received data packets is received from the receiver. 

[0005] A problem related to the arrangement described above is at- 

20 tachment of the additional byte formed by the PDCP-PDU number to the 
header field of each data packet in the convergence protocol layer PDCP. This 
increases the load in data transmission because an additional byte is transmit- 
ted in each data packet. In normal data transmission, the UMTS packet data 
service has no use for the PDCP-PDU number; it is only utilized in handover 

25 between the UMTS and the GPRS and in internal handover in the UMTS. 

[0006] A further problem related to the arrangement described 
above is generation of PDCP-PDU numbers from RLC sequence numbers. 
The RLC sequence numbers are defined consecutively for the data units RLC- 
PDU of the RLC layer. Due to delay in the system the buffer may contain a 

30 large number of data units RLC-PDU. If the RLC sequence numbers exceed 
255, which is the largest decimal number that can be represented by eight 
bits, two or more data packets may receive the same PDCP-PDU number be- 
cause the four most significant bits are removed from the twelve bits of the 
RLC sequence numbers. In that case the receiver cannot unambiguously de- 

35 fine the data packet to be acknowledged on the basis of the PDCP-PDU num- 
ber of the received packet, and reliability of handover can no longer be guar- 



anteed. 

[0007] Possible multiplexing of packet data transmissions in the 
PDCP layer may also constitute a problem because the RLC layer below the 
PDCP layer receives data packets simultaneously from several connections. 
5 Since the reliability of handover is ascertained on the basis of connection, it is 
very difficult to define RLC sequence numbers for several simultaneous con- 
nections as well as unreliable in view of handover. 

BRIEF DESCRIPTION OF THE INVENTION 

[0008] An object of the invention is to provide an improved method 
10 and an apparatus implementing the method to minimize the above-mentioned 
disadvantages. The objects of the invention are achieved with a method and 
an arrangement which are characterized by what is disclosed in the independ- 
ent claims. The preferred embodiments of the invention are disclosed in the 
dependent claims. 

15 [0009] The invention is based on using Virtual' data packet number- 

ing maintained by counters in data packet numbering in the PDCP layer. Both 
the transmitting PDCP and the receiving PDCP monitor the data packets to be 
transmitted by means of counters, and the receiving PDCP acknowledges re- 
ceived data packets by means of the counter reading, preferably in a manner 

20 corresponding to normal acknowledged data transmission, in which case data 
packet numbers need not be transmitted with the data packets. According to a 
preferred embodiment of the invention, a data packet number can be attached 
to data packets transmitted in poor transmission conditions or due to limita- 
tions of the system at certain intervals. The data packet number is not added 

25 to each data packet, yet the data packet counters can be synchronized. 

[0010] An advantage of the method and arrangement of the inven- 
tion is that in optimal transmission situations acknowledged data transmission 
can be guaranteed without having to transmit any data packet number. In non- 
optimal transmission conditions data packet numbers are transmitted in very 

30 few data packets. Another advantage is that the data packets to be acknowl- 
edged and removed from the buffer can be determined unambiguously. A fur- 
ther advantage is that the method according to the invention is not applicable 
only to internal handover between radio network subsystems of the UMTS, but 
also to handover between the UMTS and the GPRS, provided that corre- 



spending virtual data packet numbering will also be introduced into future 
GPRS versions. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] The invention will be described in greater detail by means of 
5 preferred embodiments witii reference to the accompanying drawings, in which 
[0012] Figure 1 is a block diagram of the structure of the 
GSM/GPRS system; 

[0013] Figure 2 is a block diagram of the structure of the UMTS sys- 
tem; 

10 [0014] Figures 3a and 3b illustrate protocol stacks of user data 

connections in the GPRS and UMTS; 

[0015] Figure 4 is a signalling chart illustrating a prior art handover 
process from the UMTS to the GPRS system; 

[0016] Figure 5 is a signalling chart illustrating acknowledged data 
15 transmission and acknowledgement of data packets in PDCP data transmis- 
sion; 

[0017] Figure 6 is a block diagram illustrating a functional model of 
the PDCP layer; 

[0018] Figure 7 is a signalling chart illustrating acknowledged data 
20 transmission which utilizes data packet numbering according to the invention, 
and acknowledgement of data packets in PDCP data transmission; 

[0019] Figure 8 illustrates the structure of a data packet utilized in 
the invention; and 

[0020] Figures 9a, 9b and 9c illustrate the structure of different data 
25 packets utilized in the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

[0021] In the following, the invention will be explained using as an 
example a packet radio service of the UMTS and GPRS systems. However, 
the invention is not limited to these systems, but may be applied to any 
30 packet-switched data transmission method which requires acknowledgement 
of data packets in the manner to be described below. The invention is particu- 
larly suitable both for acknowledged handover between the UMTS and the 
GPRS and for internal handover between radio network subsystems in the 
UMTS (SRNS Relocation). Thus in the former case the term receiving PDCP 



used in this description can be replaced with the corresponding function of the 
GPRS, i.e. SNDCP. 

[0022] Figure 1 illustrates how the GPRS system is built on the 
basis of the GSM system. The GSiVI system comprises mobile stations IVIS, 
5 which communicate with base transceiver stations BTS via radio paths. Sev- 
eral base transceiver stations BTS are connected to a base station controller 
BSC, which controls the radio frequencies and channels available to the base 
transceiver stations. The base station controllers BSC communicate, via an A 
interface, with a mobile services switching centre MSG, which is responsible 

10 for connection set-up/establishment and routing of calls to correct addresses. 
The MSG is assisted by two data bases which comprise information on mobile 
subscribers: a home location register HLR which contains information on all 
subscribers of the mobile communication network and on the sen/ices ordered 
by them, and a visitor location register VLR which contains information on mo- 

15 bile stations which visit the are of a certain mobile services switching centre 
MSG. The mobile services switching centre MSG communicates with other 
mobile services switching centres via a gateway mobile services switching 
centre GMSG and with a public switched telephone network PSTN, As regards 
a more detailed description of the GSM system, reference is made to 

20 ETSl/GSM specifications and to The GSM system for Mobile Communications, 
M. Mouiy and M. Pautet, Palaiseau, France, 1992, ISBN: 2-957190-07-7. 

[0023] A GPRS system connected to the GSM network comprises 
two nearly independent functions, i.e. a gateway GPRS support node GGSN 
and a serving GPRS support node SGSN. The GPRS network may comprise 

25 several serving support nodes and gateway support nodes, and typically sev- 
eral serving support nodes SGSN are connected to one gateway support node 
GGSN. Both the SGSN node and the GGSN node function as routers which 
support mobility of the mobile station and control the mobile communication 
system and route data packets to mobile stations regardless of their location 

30 and the protocol used. The serving support node SGSN communicates with a 
mobile station MS via the mobile communication network. The connection to 
the mobile communication network (Gb interface) is typically established either 
via the base transceiver station BTS or the base station controller BSC. The 
function of the serving support node SGSN is to detect mobile stations capa- 

35 ble of packet radio connections in its area, send data packets to and receive 
them from these mobile stations and to monitor the location of the mobile sta- 



tions in its service area. In addition, the serving support node SGSN connmu- 
nicates witii tine mobile services switciiing centre MSG and the visitor location 
register VLR via a signalling interface Gs and with the home location register 
- HLR via a Gr interface. The home location register HLR also contains GPRS 
5 records which are related to the packet radio service and include the contents 
of subscriber-specific packet data protocols. 

[0024] The gateway support node GGSN functions as a gateway 
between the GPRS network and an external data network PDN (Packet Data 
Network). External data networks include a GPRS network of another network 

10 operator, the Internet, an X.25 network or a private local area network. The 
gateway support node GGSN communicates with these data networks via a Gl 
interface. The data packets to be transmitted between the gateway support 
node GGSN and the serving support node SGSN are always encapsulated 
according to the GPRS standard. The gateway support node GGSN also con- 

15 tains the PDP addresses (Packet Data Protocol) of GPRS mobile stations and 
the routing data, i.e. SGSN addresses. The routing data are thus used for link- 
ing data packets between the external data network and the sen/ing support 
node SGSN. The GPRS core network between the gateway support node 
GGSN and the serving support node SGSN is a network which utilizes the IP 

20 protocol, preferably IPv6 (Internet Protocol, version 6). 

[0025] In packet-switched data transmission the connection offered 
by the telecommunications network between a terminal and a network address 
is commonly called a context. This refers to a logical link between destination 
addresses via which data packets are transmitted between the destination ad- 

25 dresses. This logical link may also exist even though no packets are transmit- 
ted, in which case it does not use the system capacity, which can be reserved 
for other connections. Thus the context differs from a circuit-switched connec- 
tion, for example. 

[0026] Figure 2 shows in a simplified manner how the third- 

30 generation UMTS network can be built in connection with an advanced GSM 
core network. In the core network the mobile services switching centre/visitor 
location register 3G-MSCA/LR communicates with the home location register 
HLR and preferably also with the service control point SCP of an intelligent 
network. The connection to the serving support node 3G-SGSN is established 

35 via a Gs' interface and to the public switched telephone network PSTN/ISDN 
as described above in connection with the GSM. From the serving support 



node 3G-SGSN a connection is established to external data networks PDN 
exactly in the same way as in the GPRS system, i.e. via the Gn interface to 
the gateway support node 3G-GGSN, which is connected to external data 
networks PDN. Both the mobile services switching centre 3G-MSCA/LR and 
5 the serving support node 3G-SGSN communicate with a radio network 
UTRAN (UMTS Terrestrial Radio Access Network) via a lu interface, which in 
view of the GSM/GPRS system combines functionalities of the A and Gb inter- 
faces. The lu interface can also be provided with totally new functionalities. 
The radio network UTRAN comprises several radio network subsystems RNS 

10 which consist of radio network controllers RNC and base stations BS, which 
communicate with the radio network controllers and are also called node Bs. 
The base stations communicate with user equipment UE, typically with mobile 
stations MS, via radio paths. 

[0027] Figures 3a and 3b illustrate protocol stacks of the GPRS and 

15 the UMTS, respectively. Definitions in accordance with these protocols are 
used in the transmission of user data in the systems concerned. Figure 3a 
shows a protocol stack used for transmitting user data between the mobile 
station MS and the gateway support node GGSN in the GPRS system. Be- 
tween the mobile station MS and the base station system BSS of the GSM 

20 network data are transmitted over the Um interface according to the normal 
GSM protocol. At the Gb interface between the base station system BSS and 
the serving support node SGSN the lowest protocol layer has been left open, 
and an ATM protocol or a Frame Relay protocol is used in the second layer. A 
BSSGP layer (Base Station System GPRS Protocol) above the second layer 

25 adds definitions of routing and quality service and signallings related to ac- 
knowledgement of data packets and management of the Gb interface to the 
data packets to be transmitted, 

[00281 Direct communication between the mobile station MS and 
. the serving support node SGSN is defined in two protocol layers, i.e. in 

30 SNDCP (Sub-Network Dependent Convergence Protocol) and LLC (Logical 
Link Layer). The user data to be transmitted is segmented into one or more 
SNDC data units in the SNDCP layer, in which case the TCP/IP or UDP/IP 
header field related to it can be compressed, if desired. The SNDC data units 
are transmitted in LLC frames to which address and control information rele- 

35 vant to data transmission has been added and in which the SNDC data units 
can be encrypted. The function of the LLC layer is to maintain a data trans- 



mission connection between the mobile station MS and the serving support 
node SGSN and retransmit damaged frames. The serving support node SGSN 
is responsible for routing data packets arriving from the mobile station MS fur- 
ther to the correct gateway support node GGSN. A tunnelling protocol (GTP, 
5 GPRS Tunnelling Protocol) is used on this connection for encapsulating and 
tunnelling all the user data and signalling transmitted via the GPRS core net- 
work. The GTP protocol is run above the IP utilized by the GPRS core net- 
work. 

[0029] The protocol stack according to Figure 3b used in transmis- 
10 sion of packet-switched user data in the UMTS corresponds to a great extent 
to the GPRS protocol stack, but there are some significant exceptions. As is 
seen in Figure 3b, in the UMTS the serving support node 3G-SGSN does not 
communicate directly with the user equipment UE, such as a mobile station 
:.:J MS, in any protocol layer, but all the data are transmitted via the radio network 
J15 UTRAN. In that case the serving support node 3G-SGSN mainly functions as 
, a router which transmits data packets in accordance with the GTP protocol to 
the radio network UTRAN. At the Uu interface between the radio network 
UTRAN and the user equipment UE lower-level data transmission occurs ac- 
cording to the WCDMA or the TD-CDMA protocol in the physical layer. In re- 
■ ::20 spect of their functions the RLC and MAC layers on top of the physical layer 
13 resemble the corresponding layers of the GSM; however,- some functions of 
the LLC layer have been transferred to the RLC layer of the UMTS. A PDCP 
ll layer on top of these mainly replaces the SNDPC layer of the GPRS system, 
and the functionalities of the PDCP layer are nearly similar to those of the 
25 SNDP layer. 

[0030] The signalling chart in Figure 4 illustrates a prior art hand- 
over from the UMTS to the GPRS. Handover of this kind is performed when 
the mobile station MS moves during packet data transmission from a UMTS 
cell to a GSM/GPRS cell which uses a different serving support node SGSN. 
30 In that case the mobile stations MS and/or radio networks BSS/UTRAfsl make 
a decision on handover (step 400). The mobile station sends a routing area 
update request (RA Update Request, 402) to a new serving support node 2G- 
SGSN. The sen/ing support node 2G-SGSN sends an SGSN context request 
(404), which defines mobility management of the mobile station and the PDP 
35 context, to the old serving support node 3G-SGSN. The sen/ing support node 
3G-SGSN sends an SRNS context request (406) to the radio network subsys- 



tern SRNS (serving RNS) that has been responsible for the packet data con- 
nection, or more precisely, to radio network controllers SRNC (serving RNC) of 
the system. In response to the request the SRNS stops sending data packets 
to the. mobile station MS, inserts the data packets to be transmitted into a 
5 buffer and sends a response (SRNS Context Response, 408) to the serving 
support node 3G-SGSN. In this connection the radio network subsystem 
SRNS, for example, defines PDCP-PDU numbers, i.e. N-PDU numbers, for 
the data packets to be inserted into the buffer. Having received mobility man- 
agement data of the mobile station MS and PDF context data, the serving 

10 support node 3G-SGSN passes them to the serving support node 2G-SGSN 
(SGSN Context Response, 410). 

[0031] If necessary, the serving support node 2G-SGSN can au- 
thenticate the mobile station from the home location register HLR (Security 
Functions, 412). The new serving support node 2G-SGSN informs the old 

15 serving support node 3G-SGSN that it is ready to receive data packets of acti- 
vated PDF contexts (SGSN Context Ack, 414). In response to this the serving 
support node 3G-SGSN requests the radio network subsystem SRNS (SRNS 
Context Ack, 416a) to forward the data packets inserted into its buffer to the 
serving support node 3G-SGSN (Forward Packets, 416b), which forwards 

20 them to the serving support node 2G-SGSN (Forward Packets, 418). The serv- 
- ing support node 2G-SGSN updates a PDF context with the gateway support 
node GGSN in accordance with the GPRS system (Update PDP Context Re- 
quest/Response, 420). After this, the serving support node 2G-SGSN informs 
the home location register HLR of the new serving support node (Update 

25 GPRS Location, 422), in which case the connection established by the old 
serving support node 3G-SGSN and the radio network subsystem SRNS is 
disconnected (424a, 424b, 424c, 424d), the necessary subscriber data are 
transmitted to the new serving support node 2G-SGSN (426a, 426b), and the 
home location register HLR acknowledges the new serving support node 2G- 

30 SGSN (Update GPRS Location Ack, 428). 

[0032] Then the serving support node 2G-SGSN checks the sub- 
scriber rights of the mobile station MS and its location and establishes a logi- 
cal link between the serving support node 2G-SGSN and the mobile station 
MS, after which the routing area update request made be the mobile station 

35 MS can be accepted (RA Update Accept, 430). In this connection the mobile 
station MS is also informed of which data packets sent by the mobile station 



10 

MS to the radio network subsystem SRNS of the UMTS before the handover 
process started have been received successfully. These data packets are 
identified with PDCP-PDU numbers generated as described above. The mo- 
bile station MS acknowledges acceptance of the routing area update request 
5 (RA Update Complete, 432), and at the same time the serving support node 
2G-SGSN is informed of which data packets transmitted by the serving sup- 
port node 3G-SGSN via the radio network subsystem SRNS before the hand- 
over process started have been received successfully by the mobile station 
MS. After this, the new serving support node 2G-SGSN can initiate transmis- 
10 sion of data packets via the base station system BSS (434). 

[00331 The following table illustrates generation of 8-bit PDCP-PDU 
numbers from RLC sequence numbers and problems caused by this. 
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h- 15 [0034] It can be seen in the table, for example, how 12-bit decimal 

i;; numbers 94, 350, 606 and 862 are converted into 8-bit numbers' by the 
;:J method described above. Since only the eight least significant bits are taken 
:; Into account in the conversion, all the above-mentioned numbers receive the 
same 8-bit binary representation. If the buffer thus contains nearly 900 data 
20 units RLC-PDU, the data units containing the above-mentioned RLC sequence 
numbers receive the same 8-bit representation. When the receiver acknowl- 
edges successfully received data packets to the transmitter, the transmitter 
cannot know unambiguously in the basis of acknowledged 8-bit numbers 
which data packet can be removed from the buffer. 
25 [0035] Figure 5 shows how data transmission is acknowledged and 

how data packets travel when acknowledged transmission is used in PDCP 
data transmission. A PDCP entity receives a request (PDCP-DATA.request, 
500) to transmit data packets from the user as well as data packets PDCP- 
SDU (Service Data Unit) together with the request. Being network layer data 
30 packets, these packets are also called N-SDUs. The PDCP entity compresses 
the header fields of the data packets and sends the resulting data packets to 



the PDCP-PDU RLC layer (RLC-AM-DATATequest, 502) together with the 
identity data of the radio link. The RLC layer is responsible for transmitting 
(send, 504) data packets PDCP-PDU and for acknowledging successful 
transmission (send ack, 506). In the PDCP entity the data packets N-SDU are 
5 inserted into a buffer, from which they are not removed until an acknowledge- 
ment (RLC-AM-DATA.conf, 508) of successful transmission of data packets to 
the receiver is received from the RLC layer. The receiving PDCP receives the 
PDCP-PDUs transmitted from the RLC layer (RLC-AM-DATA.indication, 510), 
in which case the PDCP entity decompresses the data packets PDCP-PDU. 

10 Thus the original data packets N-SDU can be restored and will be forwarded 
to the user (PDCP-DATA.indication, 512). 

[0036] Figure 6 shows a functional model of the PDCP layer in 
which one PDCP entity is defined for each radio bearer. Since in the existing 
systems a separate PDP context is defined for each radio bearer, one PDCP 

15 entity is also defined for each PDP context, and thus a certain RLC entity is 
defined for the entity in the RLC layer. In the GPRS system N-PDU numbering 
is performed on the basis of the PDP context, for which reason the same prin- 
ciple has also been suggested for the UMTS system. In that case the PDCP 
layer would perform corresponding numbering of data packets on the basis of 

20 the PDCP entity. If similar numbering is used both in the GPRS and in the 
UMTS, there should be no problems in the handover between the systems. 
However, this requires addition of one byte to each PDCP data packet, which 
uses the transmission capacity of the UMTS system, particularly because this 
additional byte is needed only in handover between the UMTS and the GPRS 

25 and in internal handover between the radio network subsystems of the UMTS. 

[0037] In principle, the functions of the PDCP layer can also be im- 
plemented by multiplexing several PDP contexts in the PDCP layer, in which 
case one RLC entity in the RLC layer below the PDCP layer receives data 
packets simultaneously from several radio bearers. In that case the data 

30 packet numbers defined on the basis of the PDCP entity are mixed in the RLC 
layer and it is difficult to separate data packets arriving from several radio 
bearers from one another, particularly if the data packet numbering is based 
on RLC sequence numbering. 

[0038] Lossless handover, in which data packets are not lost in the 

35 handover process, is needed in reliable data transmission which utilizes ac- 
knowledged transmission. This sets certain requirements for the RLC layer of 
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the UMTS system: the RLC layer has to be in the acknowledgement mode and 
the RLC must be able to send the data packets in the right order. If these con- 
ditions are met, reliable handover can be performed from the GPRS to the 
UMTS according to a preferred embodiment of the invention without having to 
5 transmit any data packet number, 

[0039] According to the invention, a PDCP-PDU sequence number 
is defined for the first data packet of the packet data connection and a prede- 
termined numerical value, e.g. 0, is set as the initial value for this number in 
the counter both in the transmitting PDCP and in the receiving PDCP/SNDCP. 
10 The invention can be advantageously applied both in reliable handover be- 
tween the UMTS and the GPRS and in internal handover (SRNS Relocation) 
between radio network subsystems in the UMTS. In the former case, the term 
receiving PDCP used In this description can be replaced with the correspond- 
ing function of the GPRS, i.e. SNDCP. 

; j: 15 [0040] The method according to the invention will be illustrated with 

; = Figure 7. When the transmitting PDCP receives (700) a data packet PDCP- 
■ SDU from the transmitter, it inserts the data packet PDCP-PDU into the buffer 

^ 5 and logically adds a PDCP-PDU sequence number (702) to this data packet. 
The transmitting PDCP transmits the data packet PDCP-PDU and the PDCP- 

:320 PDU sequence number logically attached to it to the RLC layer (704) and adds 
one (706) to the counter that determines the value of the PDCP-PDU se- 

riji quence number. The RLC layer may also optionally define the ratio between 
the PDCP-PDU sequence number and the last RLC sequence number of the 
data packet and store it in memory (708). The RLC layer is responsible for 

r^25 transmission of PDCP-PDU data packets between the transmitter and the re- 
ceiver (710), the data packets PDCP-PDU being split into data units RLC-PDU 
for transmission and numbered with RLC sequence numbers. When the re- 
ceiving PDCP receives (712) a data packet PDCP-PDU from the RLC layer, it 
adds one (714) to the counter that defines the value of the PDCP-PDU se- 
30 quence numbers and transmits the data packet PDCP-SDU to the next layer 
(716). An acknowledgement of a successfully received data packet is sent to 
the transmitter (718) in the RLC layer, and the transmitting RLC transmits this 
acknowledgement to the transmitting PDCP (720). In response to the ac- 
knowledgement, the transmitting PDCP removes the data packet PDCP-SDU 
35 in question from the buffer (722), The correct data packet PDCP-SDU to be 
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removed is determined preferably by means of a PDCP-PDU sequence num- 
ber logically attached to the data packet. 

[0041] Thus data packet numbering according to the invention is 
preferably performed Virtually, which means that no separate data packet 
5 numbers are added to the data packets, but the transmitted data packets are 
updated on the basis of the counters and the receiving PDCP and the trans- 
mitting PDCP can ascertain successful transmission of data packets on the 
basis of counter values. Consequently, in an optimal case acknowledgement 
of data packets according to the invention can also be made to correspond to 

10 the acknowledgement of data packets in normal PDCP data transmission de- 
scribed above. The actual handover process can be performed according to 
the prior art, e.g. as described above in connection with Figure 4. It should be 
noted that even though the invention has been described in connection with a 
handover process, the Virtuar data packet numbering according to the inven- 

15 tion can also be used in normal acknowledged data transmission in which the 
receiver and the transmitter remain the same, whereas in the handover proc- 
: ''i ess one party changes. 

\ [0042] In some interference situations, e.g. when the network is 

congested or there is disturbance on the radio path, the RLC layer cannot 
: =20 guarantee acknowledged data transmission. A maximum value is typically de- 
; = fined for the transmitting RLC, which is either a number of retransmissions or a 
; ^ period during which the transmitting RLC tries to retransmit the same data 
; - packet, if the maximum value is exceeded, the RLC layer informs the receiving 
PDCP of this. The transmitting PDCP removes the corresponding data packet 
25 from the buffer in connection with the next successful data packet transmis- 
sion. This also happens when several successive data packets have lost. The 
lost data packets are removed from the buffer when an acknowledgement of 
the next successfully transmitted data packet is received. If the RLC can in- 
form the PDCP layer of all lost data packets, the receiving PDCP can update 
30 the PDCP-PDU sequence number correctly, and thus the sequence number 
counters of the transmitting PDCP and the receiving PDCP remain synchro- 
nized. However, in some interference situations the RLC layer cannot guaran- 
tee that the PDCP layer is informed of lost data packets, in which case the 
PDCP-PDU sequence number counters may become asynchronous in the 
35 transmitting PDCP and receiving PDCP. 
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[0043] According to a preferred embodiment of the invention, this 
asynchronization can be corrected by sending a PDCP-PDU sequence num- 
ber with the data packets PDCP-PDU at certain intervals. When the receiving 
PDCP receives a transmitted data packet PDCP-PDU and a PDCP-PDU se- 
5 quence number'attached to it, it compares the PDCP-PDU sequence number 
with the counter value, and if necessary, updates the counter value to corre- 
spond to the PPDCP-PDU sequence number of the received data packet. At- 
tachment of the PDCP-PDU sequence number to the data packet PDCP-PDU 
can be preferably defined in the settings of the system, in which case the 

10 PDCP-PDU sequence number can be attached to every tenth or to every hun- 
dredth data packet PDCP-PDU, for example. It is also possible to define that 
the PDCP-PDU sequence number is always attached to the data packet 
PDCP-PDU in connection with a certain process, e.g. after discard of the data 
packet in the RLC layer described above or after a handover process. Thus 

15 the PDCP-PDU sequence number does not need to be attached to each data 
packet even in poor transmission conditions but re-synchronization of the sys- 
tem can be preferably guaranteed by sending the PDCP-PDU sequence num- 
ber only in some, preferably in very few, data packets. Naturally, data trans- 
mission is not reliable in the situation described above because data packets 

20 may disappear, but transmission of data packets can be continued because 
the transmitter and the receiver are synchronized rapidly. 

[0044] Figure 8 illustrates a structure of the PDCP-layer data packet 
PDCP-PDU according to the invention. The data packet PDCP-PDU according 
to the invention can be used both when the PDCP-PDU sequence number is 

25 omitted from the data packet and when it is added at certain intervals defined 
by the system. The first byte of the data packet PDCP-PDU comprises one bit 
(N) whose value indicates whether a PDCP-PDU sequence number will be 
attached to the data packet PDCP-PDU or not. Bit O indicates whether an op- 
timisation algorithm is used for forming a data packet PDCP-PDU. If bit O re- 

30 ceives value 1 , optimisation is used and it Is defined more accurately with a 
12-bit optimisation field (OPT), which contains four bits from the first byte of 
the data packet PDCP-PDU and all bits of the second byte. Values of the op- 
timisation field are used for determining the compression method of the 
header field and the data packet type, for example. On the basis of the optimi- 

35 sation field values the receiving PDCP can perform opposite procedures on 
the data packet, such as decompression of the header field. There are no pre- 
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determined values for the optimisation field, but the transmitter and the re- 
ceiver always agree on them separately in the negotiation of PDCP parame- 
ters. A PDCP-PDU sequence number field containing one byte, i.e. 8 bits, is 
optional and is used if bit N receives value 1. In that case the PDCP-PDU se- 
5 quence number is added to the data packet PDCP-PDU. The actual user data 
to be transmitted in the data packet are attached after these definitions. 

[0045] The data packet structure described above is only an exam- 
ple of how a PDCP-PDU data packet according to the invention can be 
formed. Alternatively, the information included in the data packets PDCP-SDU 
10 arriving from the upper application-level layers can be forwarded from the 
PDCP layer using three different data packets PDCP-PDU: PDCP-No-Header- 
PDU, PDCP-Data-PDU and PDCP-SeqNum-PDU, which are illustrated in Fig- 
ures 9a, 9b and 9c, respectively. 

[0046] According to Figure 9a, the PDCP-No-Header-PDU com- 

: 15 prises only data, i.e. the PDCP-SDU received from the upper layers as such. 
Thus the PDCP layer does not add any information to the PDCP-SDU, in 
which case the whole PDCP-PDU is used for transmitting payload. Conse- 
quently, the PDCP-No-Header-PDU can be preferably used in acknowledged 
data transmission described above in which data packet numbering is main- 

' 20 tained by means of counters. 

5 [0047] One byte (8 bits) has been added to the PDCP-Data-PDU of 

f Figure 9b to indicate the PDU type in question and the compression method to 
I be applied to the header field of the PDCP-SDU. In fact, the tasks of the 
PDCP layer include functions related to improvement of channel capacity, 
25 which are typically based on optimisation of data packet header fields by 
means of various compression algorithms. 

[0048] The PDCP-SeqNum-PDU of Figure 9c also comprises a cor- 
responding extra byte for indicating the PDU type and the compression 
method to be applied to the PDCP-SDU header field. In addition to this, a 
30 PDCP-PDU sequence number with a length of two bytes, i.e. 16 bits, has been 
added to it. Both in the PDCP-Data-PDU and in the PDCP-SeqNum-PDU the 
PDU type is indicated with three bits, and thus it separates the PDCP-Data- 
PDU from the PDCP-SeqNum-PDU. The compression method to be used is 
indicated with five bits. 
35 [0049] One of the functions of the PDCP layer is to transmit data 

packets PDCP-PDU and, if necessary, PDCP sequence numbers related to 
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the packets to a new radio network subsystem in internal liandover (SRNS 
Relocation) between radio network subsystems in the UMTS. During the 
handover the interference situations described above may render the data 
packet counters asynchronous and cause a situation in which the transmitting 
5 PDCP has sent a data packet (e.g. PDCP-No-Header-PDU) but it has not 
been transferred to the new receiving PDCP. When the maximum value of re- 
transmissions has been exceeded, the discard function of data packets is ter- 
minated in the RLC layer. The transmitting RLC informs the transmitting PDCP 
of this, and the transmitting PDCP removes the data packet in question from 
10 the buffer. As a result of this, the receiving PDCP waits for a data packet 
which is no longer in the buffer of the transmitting PDCP, and thus data packet 
counters cannot be synchronized. Such an error situation may result in clear- 
ing of the radio bearer. 

[0050] According to a preferred embodiment, the transmitting PDCP 
^ ^ 15 is made to send a data packet number with the first data packet in the buffer, 
.1 i.e. a PDCP-SeqNum-PDU data packet is used. Consequently, the receiving 
: i PDCP synchronizes its data packet counter with the transmitting PDCP utiliz- 
!: ing the data packet number sent, which is the quickest possible way to 
achieve synchronization. Furthermore, data transmission can be continued as 
- ::^20 soon as the counters have been synchronized, and it is unnecessary to clear 
the radio bearer, which might result in greater loss of information. After syn- 
vl chronization, data transmission can be continued using the data packet format 
defined for the radio bearer, e.g. PDCP-No-Header-PDCP data packets. 

[0051] It is obvious to a person skilled in the art that as the technoi- 
25 ogy advances, the inventive concept can be implemented in various ways. The 
invention and its embodiments are thus not limited to the examples described 
above but may vary within the scope of the claims. 



